Network owners and operators would like to be able to make customers accountable for any problems they cause to their network. One of the biggest problems for most networks is path congestion. When a network is congested then it is not able to provide good service to any of the customers of that network and thus its reputation may suffer. Accountability is generally done on the basis of the volume of traffic passed into the network by a given customer. Mechanisms allowing for collection of network path characteristics such as level of congestion are useful as such information may be used for more accurate accountability purposes. Such characteristics may also give advance notice of potential problems in the network and may enable the network to react to problems before they become too severe.
We start by presenting some basic concepts to facilitate the understanding of the mechanisms that are presented further on.
Packets
Data networks usually split the data they carry into small units known as packets. The actual communication between endpoints is controlled by various communication protocols. Each communication protocol required to carry the data across the Internet adds a header that contains the required information to enable the data exchange between the end hosts (usually a source host and a destination host). In the Internet, one of the most common types of packet consists of a payload that contains the data generated by an application running at the source, encapsulated by a Transmission Control Protocol (TCP) header which ensures the reliable delivery of the data, encapsulated again by an Internet Protocol (IP) header, which ensures that the data reaches the destination host for which it is aimed. The TCP header includes a unique sequence number (to allow the data to be reconstructed at the destination) and the IP header includes the IP addresses of the source and destination host.
Distributed Bandwidth Sharing and Congestion
Data traversing the Internet will follow a path between a series of routers, controlled by various routing protocols. If many paths need to use the same router in the network, this router can get congested (packets experience delays whilst using that network path). If sources persisted sending traffic through that router it may become overloaded or even fail. If sources still persist in sending traffic around this bottleneck it could force more routers to fail, and if the phenomenon keeps spreading, that can lead to a congestion collapse for the whole Internet—which occurred regularly in the mid-eighties.
The solution to that problem has been to ensure that sources take responsibility for the data-rate they send over the Internet by implementing congestion control mechanisms. Sources monitor path characterisation metrics to detect when the path their data is following is getting congested, in which case they react by reducing their throughput—while they usually slowly increase it when there is no sign of the path getting congested.
The typical path characterisation metrics sources monitor are the average roundtrip time (RTT) for the data path, the variance of the roundtrip time (referred to as jitter), and the level of congestion on the path, which is the primary parameter influencing the data-rate adaptation of a source sending data over a congested path.
The congestion level can be signalled either implicitly (through congested routers dropping packets) or explicitly (through mechanisms such as explicit congestion notification—see next subsection). Recently the most common option has been implicit signalling. Historically, routers would drop packets when they got completely saturated (which happens when a traffic burst cannot be accommodated in the buffer of the router). This policy is called “Droptail”. The problem with this is that it can lead to a phenomenon known as global synchronisation which reduces the overall efficiency of the network. An improvement has been proposed whereby routers monitor the average queue length in their buffer. When this is higher than a given threshold, the router starts to drop packets with a probability which increases with the excess length of the queue over the threshold. This policy is called Random Early Detection (RED). It is widely used in today's internet because it allows sources to react more promptly to incipient congestion. Sources using TCP are able to detect losses because a packet loss causes a gap in the sequence; whenever a source detects a loss, it halves its data-rate, which alleviates the congestion on the router at the bottleneck.
Explicit Congestion Notification
Explicit Congestion Notification (ECN) [ECN] further improves on RED by using a two-bit ECN field in the IP header to signal congestion. It runs the same algorithm as RED, but instead of dropping a packet, it sets its ECN field to the Congestion Experienced (CE) codepoint. The ECN standard requires the sender to echo any congestion mark signalled in the data; for instance, a TCP receiver sets the Echo Congestion Experienced (ECE) flag in the TCP header, which the TCP source interprets as if the packet has been dropped for the purpose of its rate control. In turn the source will reduce its data-rate and will set Congestion Window Reduced (CWR) in the TCP header of the next packet.
The four values of the two-bit ECN field are:                Not-ECT (Not ECN Capable Transport), which signifies that the packet belongs to a flow that doesn't support ECN        ECT(0) and ECT(1), which signify that the packet belongs to a flow that supports ECN but and that upstream routers haven't had to mark the packet.        (CE) Congestion Experienced which signals to the receiver that a packet has experienced congestion along its path.IP Tunnels        
In the context of a data network, tunnelling consists of encapsulating one protocol header inside another protocol header. The aim is to improve the network service, for instance in terms of connectivity (it may allow data to get across a network it couldn't get across otherwise) or of security (the data may be encrypted so it cannot be used if it is intercepted).
A special case of tunnels are IP-in-IP tunnels where the original header is retained intact, and simply encapsulated in another standard IP header, at the entrance of the tunnel. The outer IP header source and destination addresses identify the “endpoints” of the tunnel while the inner header preserves the original source and destination addresses for the packet. As the packet traverses the tunnel, the outer header may be modified as the header of any other packet on the same path. When the packet reaches the other end of the tunnel, decapsulation occurs: the outer header is stripped off, the original header fields are updated if necessary and the packet is forwarded to its originally-intended destination.
Re-Feedback
The re-Feedback proposal [Briscoe05c] provides a mechanism whereby the congestion information that a receiver sends back to a source can be re-inserted into the forward data path, thus allowing nodes along the path to see downstream congestion information as well as upstream information. This allows network providers to trace the source of any congestion and hold appropriate customers to account for this congestion. The proposal also outlines how a similar mechanism could work for other characterisation metrics such as RTT.
Pre-Congestion Notification
Pre-Congestion Notification (PCN) [PCN] is a mechanism for protecting the quality of service of certain flows within a given region of the network. Flows are only admitted to the network if they won't cause too much congestion. In order to work out if a flow can be admitted, the incipient congestion inside the network is monitored. This allows the ingress node to predict what the edge-to-edge congestion will be for any given flow asking for admission.